Made _react synchronous but the _speak async. - #3

Thanks for this, and for saying "please check before distributing". That turned out to be the right call.

There's a problem with the new ordering. The three thresholds are tested lowest first now:

if self._counter >= soft:        # 1
   speaktype = "soft"
elif self._counter >= medium:    # 3
    speaktype = "medium"
elif self._counter >= chaos:     # 6
    speaktype = "chaos"

soft is the lowest of the three, so that first branch is true for every reaction Greg ever has and the two elifs under it never get a look in. I ran both versions over the same tap counts with the default thresholds:

He'd keep his mood and his face, and the bar would still climb, but he'd only ever say soft lines. No medium, no chaos, however hard anyone leaned on him. That's why the original tests highest first.

It merges cleanly onto main too, so nothing would have stopped it going in.

The split itself is fine. One thing it changes is that greg.poke used to wait for the speaking before it returned and now it doesn't. Probably for the better, but I'd rather we changed that on purpose than have it come along for the ride.

On whether it fixes #2, I don't think it does. The traceback ends here:

File ".../pyatv/protocols/raop/audio_source.py", line 598, in open
miniaudio.DecodeError: ('failed to init decoder', -1)

That's the HomePod's own media player fetching the audio and failing to start decoding it, which is two hand-offs past anything Greg controls. By that point Greg's call has gone to tts.speak, and tts.speak has gone to media_player.play_media. Moving the call earlier in the chain does shift the timing though, and the fault in #2 comes and goes, so I can see why it looked fixed.

The bit of your report I keep coming back to is the caching. Every failing call logs as cache=True, and the manual one that works you sent with cache: false:

action: tts.speak
data:
  message: Something touched me...
  media_player_entity_id: media_player.woonkamer_homepod
  cache: false

Greg doesn't set cache at all, so Home Assistant's default of true applies. Same speaker, same engine, same text, and that's the only difference between the call that works and the one that doesn't.

Two things I'd try, in this order. First, re-test on 1.6.0. Those logged calls have no language field, which puts them before 1.5.5, and _speak has sent one ever since along with a fix for a locale bug that was silencing him outright. It might look quite different now. If it's still going, then try cache: false. If that's what does it, it's a couple of lines in _speak rather than a restructure, and we can test it against your HomePod before it goes anywhere near a release.

One thing on my side either way. _speak calls tts.speak with blocking=False, so the failure never comes back to Greg. It lands in HA's log, which is where you found it, and Greg's own error handling never sees a thing. Blocking isn't the answer, since for RAOP he'd sit there waiting for the whole file to stream. But it does mean Greg can't currently tell anyone he's failed to speak, and I should sort that out separately.